Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/list/list-minutes-91jul.txt

Text File | 1993-02-17 | 12KB | 312 lines

CURRENT_MEETING_REPORT_

Reported by David Lippke/UTEXAS

LIST Minutes

The Automated Internet Mailing List Services Working Group had two
separate meetings, one on Wednesday morning and another the following
morning.  The second meeting was simply a continuation of the first and,
consequently, these notes do not distinguish between the two.  Further,
the order of presentation here doesn't necessarily reflect the order of
discussion at the meetings (where each topic was generally visited more
than once).

To start things off, we reviewed why the Working Group exists and what
we are, and are not, trying to do.  The view expressed was the
following:


     We are here because dealing with Internet mail lists is painful
     for everyone involved --- users, list owners, and postmasters
     alike.  Current Internet mailing list services generally lack
     fundamental features such as access control and standardized
     archive maintenance.  In short, the Internet mailing list world
     is a very primitive one...  and one which is in serious need of
     improvement.  The Working Group exists to address this need.
     However, we are NOT here to create the ultimate group
     communication system.  Although list-style group communication
     should eventually become part of an integrated group
     communication system, our goals are more focused and short
     term.  The feeling is that we have to learn to walk before we
     can run.


After establishing this, the group went on to discuss the agenda for the
meetings.  Two major potential directions were identified.  Either we
could define a baseline user interface or we could spend the time trying
to develop a picture of the phase 2 list server world.  The following
list of pros and cons was reviewed:

Reasons to define a baseline interface:


  1. Damage control in the name of minimizing user confusion.
     Alternative view:  we need to define the first few articles of a
     ``user's bill of rights'' (e.g., users have the right to receive
     confirmation of all transactions, users have the right to see
     whether or not they are subscribed to a given list, etc).

  2. Enable implementors to begin work now.


                                   1





  3. We can define the baseline quickly (assumption).

  4. It's a fail-safe strategy for the Working Group (i.e., recognize
     that there's a significant chance that the phase 2 work will fail.
     If so, the Working Group will have at least accomplished
     something).


Reasons to NOT define a baseline interface:


  1. Perhaps we would codify something that won't fit future models
     well.
  2. Perhaps the subset we define now will be too limited to be useful.


After some discussion, we decided to attempt a definition of the
baseline's contents and use that process to learn more about the problem
and to see if we hit any show stoppers (which would indicate that
defining a baseline user interface at this time is not the proper thing
to do).

Thus, we began discussing a long list of functions and design issues.
We rated each of the functions as ``in'' or ``out'' of the baseline
interface and discussed each of the design issues long enough to develop
views on how each should be treated.

Each of these items is given separate treatment below, but to jump
straight to the end, the final conclusion was that we were satisfied
with our efforts to define a baseline user interface and that enough
functionality was contained within it to warrant its publication.


BASELINE COMPONENTS


   o INCLUDED: Subscribe/Unsubscribe capability
     Discussion:  An obvious conclusion.  Also concluded that any
     subscription policy was allowable (e.g., open, closed, by service
     area, etc), but that the user is always owed a confirmation,
     explanation, or denial.  See more general comments in the ISSUES
     section.

   o INCLUDED: List parameter review capability
     Discussion:  If users can see that a list exists, then they should
     be able to review its operational definition (e.g., see who the
     owner is, see what the subscription policy is, etc).  Also, there
     was a general consensus expressed that a list's definition should
     include a ``keywords'' parameter which could be used as an aid in
     searching.  The expression of the various parameters is not to be
     specified.

   o INCLUDED: List subscriber review capability

                                   2





  Discussion:  If users can see that a list exists, then they should
  be able to obtain a list of its subscribers, UNLESS list policy
  dictates otherwise.  In all cases, requesting users are owed either
  the list or an explanation of why they cannot retrieve it.

o INCLUDED: List of lists capability
  Discussion:  Users should be able to obtain a list of all lists a
  given list server knows about (and they're allowed to know exist).
  We agreed that list servers needed to somehow identify for what
  ``domain'' they spoke, but tabled the implementation details for
  discussion on the Working Group list.

o INCLUDED: Various minor commands (HELP, POLICY, STOP, etc.)
  Discussion:  We resolved that this wasn't worth spending time on
  and that the details should be worked out on the Working Group
  mailing list.

o EXCLUDED: Per-user options
  Discussion:  This was tabled as being too demanding of
  implementations and because we predicted that there would be no
  quick agreement on what a set of baseline options should be.  After
  the initial conclusion, it was later countered that users had a
  fundamental right to conceal their membership on a list and that
  the implementation of this was not overly complex even with
  simple-minded sendmail alias implementations.  The ensuing
  discussion revealed that while the Mailbase implementors currently
  allowed per-user concealment, they will soon remove that capability
  since their users had raised the opposite argument (i.e., that they
  had a right to see who they were talking to when they posted a
  message to a list).  This counter-counterpoint showed that the
  issue was a debatable one.  Since our razor was that if something
  was debatable, it was not baseline, we returned to our initial
  conclusion.

o EXCLUDED: Archive Searching and Archive Retrieval
  Discussion:  Although it was universally accepted that archival
  services are important, exploration of this topic revealed a number
  of sticky issues which we felt could be not quickly resolved.
  Difficulties ranged from problems related to the (previously agreed
  upon) need for program- interpretable list server responses to the
  quagmires of search method specification.  Thus, the whole area of
  archive services was booted.  The interim suggestion is that the
  output of a list parameter review mention how the archives are to
  be obtained.

o EXCLUDED: File services
  Discussion:  This died for reasons similar to those that killed the
  inclusion of archive services.

o EXCLUDED (with proviso):  Authentication
  Discussion:  All cookie approaches do significant damage to the
  current pattern of user interaction.  We have no experience with


                                3





     these approaches nor have we spent time looking for alternatives.
     Consequently, the introduction of such a facility in the baseline
     was deemed a real bad idea.  HOWEVER, the baseline definition will
     mandate that all list server transactions be logged for X (TBD)
     period of time in a way that allows listmasters to reverse
     transactions, should the need arise.  Also, any transaction which
     affects a user (mail address) should result in a
     confirmation/informational message being sent to that user (mail
     address).  The feeling was that this is similar to what goes on now
     and at least offers some degree of reactive protection.
     It was also noted that PEM does not address the question of whether
     or not a person can speak authoritatively for a given mail address
     (although it may diminish the exposure since one at least knows
     *who* caused the trouble).

   o EXCLUDED: Proxy Operations
     Discussion:  Proxy operations are desirable, but we uncovered a
     complex set of problems and possible approaches once we dug into
     the issue.  Also riding against their inclusion was the lack of
     solid authentication (these two issues seem to feed on each other
     ...).


DESIGN ISSUES / PHILOSOPHIES


   o LISTSERV Compatibility
     The LISTSERV command set and interaction methods/patterns are the
     de facto standard.  We should not be afraid to vary from that
     standard, but we should only do so when there is ample cause.

   o Where should mail commands be sent?
     Directly to the list server agent address for the most part, but
     mail to listname-request and listname-owner should do a reasonable
     thing (which, even on BITNET, could be simple aliases to the list
     owner).

   o How should the results of commands be returned?
     By default, they should be returned via the mechanism the commands
     were received.  Command results should also be
     machine-interpretable.  The intent was that we should define how
     this is done, but the issue was tabled for Working Group list
     discussions.  In any case, the view is that both humans and GUI
     tools need to be able to make requests and understand the
     response(s).

   o General syntax rules
     Tabled for discussion on the list.

   o Channels and other provisions for upwards compatibility.
     Part of the above and likewise tabled.



                                   4





o General note on command interaction
  Users are always owed a message confirming (directly or indirectly)
  the reception and disposition of their requests.

o Identity of list servers
  A minor issue, but list servers should identify themselves (general
  type, version number, etc.)  in some appropriate way during most
  transactions.  (where ``appropriate'' and ``most'' is TBD on the
  list).

o Header handling
  Although further debate is assured, the group came up with the
  following guidelines in regard to how list mail should be sent to
  subscribers.


   1. Steps should be taken to ensure that rejections are never
      routed back to a list.

   2. ``Sender:''  and SMTP return path should never be set to the
      list address.

   3. Header trace information should not be stripped.

   4. The list equivalent of a ``Received:''  line is needed (e.g.,
      Exploded:).  Resolved to work with the 822 Extensions folks on
      this.

   5. Messages from a list should be unambiguously identifiable as
      coming from that list.  Header extensions may be required for
      this as well.

   6. ``Reply-To:''  should not be modified.



                                5





Attendees

James Conklin            [e-mail]
Peter Deutsch            [e-mail]
Johnny Eriksson          [e-mail]
Erik Fair                [e-mail]
Jill Foster              [e-mail]
Ned Freed                [e-mail]
James Galvin             [e-mail]
Neil Katin               [e-mail]
Darren Kinley            [e-mail]
Mark Knopper             [e-mail]
Vincent Lau              [e-mail]
Eliot Lear               [e-mail]
Louis Leon               [e-mail]
David Lippke             [e-mail]
Joseph Malcolm           [e-mail]
Chris Myers              [e-mail]
Mel Pleasant             [e-mail]
Jan Michael Rynning      [e-mail]
Harri Salminen           [e-mail]
Larry Snodgrass          [e-mail]
Gregory Vaudreuil        [e-mail]
Chris Weider             [e-mail]
John Wobus               [e-mail]
Russ Wright              [e-mail]



                                   6